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STATUS OF CLAIMS 

Allowed claims: None 

Claims objected to: None 

Claims rejected: 1-8 and 34-49. 
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II. GROUNDS OF REJECTION TO BE REVIEWED ON APPEAL 

The rejections presented for review are as follows: 
The rejections of claims 1-8 and 34-49 under 35 U.S.C. §102 (e) as being 
anticipated by U.S. Patent No. 6,282,522 issued to Davis et al. 
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III. ADDITIONAL ARGUMENTS 



A. Davis is not an Enabling Reference 

In the examiner's answer, it is argued that since "the reference specifically 
discloses that the functionality of the virtual card is provided for. Therefore, the Davis 
reference not only suggests that a virtual card might be used, hypothetically, but states 
that the system and method as set forth is operable for either a physical card or a virtual 
card. While specific reference to the virtual card is contained in only one location within 
the Davis reference, that portion clearly states that operability is afforded to either a 
physical or virtual card. And, accordingly, the components have operability for either 
being a physical card database or a virtual card database, etc." 

The citation from Davis that is relied upon by the examiner is found in Column 
11:10-14, which recites, "By way of example, other forms that a stored- value card may 
take are any electronic representations. Further, the functionality of stored- value card 5 
may be implemented in software on client terminal 204, that is card 5 may be a 'virtual' 
card." (underline added) Applicant respectfully disagrees with the examiner's assertion 
that this citation "states that the system and method set forth is operable for either a 
physical card or a virtual card" because the examiner does not provide rationale or 
evidence as to why this functionality is to be imported to each of the many devices 
described in Davis. 

The examiner appears to be saying that since a virtual card might be used, it is 

thus inherent that all of the other required components of the claims related to a virtual 

card are found in Davis. Applicant respectfully submits examiner's assertions in Davis 

regarding operability afforded to either a physical card or a virtual card do not meet the 

standards for inherency described in the MPEP. In MPEP 2112 IV, Examiner Must 

Provide Rationale or Evidence Tending to Show Inherency, it states, 

The fact that a certain result or characteristic may occur or be present in the 
prior art is not sufficient to establish the inherency of that result or 
characteristic. In relying upon the theory of inherency, the examiner must 
provide a basis in fact and/or technical reasoning to reasonably support the 
determination that the allegedly inherent characteristic necessarily flows from 
the teachings of the applied prior art. 
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Applicant respectfully submits the examiner does not provide a basis of fact or technical 
reasoning to support a conclusion that characteristics attributed to Davis are inherent in 
the manner set forth in the MPEP. Hence, for this reason, Applicant believes the rejection 
under U.S.C. §102 (e) is improper. 

B. Davis does not teach a Single Device as Required 
1. Elements not on a Single device 

As will be described in more detail as follows, independent of whether Davis 
teaches the asserted virtual functions, Davis does not describe a single device that 
possesses all of the limitations of the pending claims nor is one identified in the Final 
Rejection under §102 (e). 

Claims 1 and 41 both recite a single device, namely, "server computer" 
comprising a "virtual smart card database," a "hardware security module," a "smart card 
emulator" and a "pseudo card reader module." Applicant respectfully submits that the 
Final Office Action does not identify a single device with the limitations described with 
respect to the pending claims, such as recited claims 1 and 41. Further, Applicant 
respectfully submits that Davis does not teach such a device nor can such a device be said 
to be inherent in Davis. 

In further detail, claims 1 and 41 recite "a virtual smart card database," and "a 
hardware security device" that are both part of the required "server computer," i.e., the 
single device. In the Final Rejection, these limitations of the OPAL server computer of 
claims 1 and 41 are mapped to the payment server 206 of Davis shown in Figs. 4-9, i.e., 
the virtual card database is mapped to database 223 (see Fig. 4), which Column 10:60-63 
of Davis describes as being managed by the payment server 206. The Final Rejection 
also appears to map a "hardware security device" on the payment server 206 to the 
"security card" in Davis. For instance, Davis (Column 23: 61-63) recites, "Once the 
payment server had produced the TSK, it may decrypt the draw request and process the 
draw request in any suitable fashion with the security card." Thus, the Final Rejection 
appears to equate the payment server 206 with the required server computer. 

But, the pending claims describe that the "server computer" comprises: 
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the smart card emulator that receives smart card commands from a pseudo 
card reader module and processes said commands in conjunction with said 
virtual smart card database and said hardware security module, said smart 
card emulator arranged to retrieve one of said records from said virtual smart 
card database, and to deliver said monetary balance to said hardware security 
module and to store said encrypted decreased monetary balance received 
from said hardware security module in said retrieved record. 

To teach this limitation, the Final Rejection points, via various citations, to a number of 
different devices in addition to the payment server 206. These devices include a "stored- 
value card 5", a "physical card reader 210," a "merchant server 208," a "clearing and 
administration system 110," a "personal computer" (Column 4:3-5, Column 7:6-21). In 
addition, these devices include "a security card 218," a "client terminal 204," a 
"concentrator 212," a "managing database 223," a "merchant server 208," and a 
"payment server 206" (Column 8: 22-24, Column 10:50-65, Column 11:48-57; Column 
14: 55-58, Column 16:22-38). It is not clear from the citations or the reasoning provided 
in the Final Rejection how the functions of these different devices anticipate the "server 
computer" of the pending claims because the Final Rejection does not identify a single 
device from these citations that is performing the required functions necessary to 
anticipate the pending claims. 

2. Smart Card Emulator not on the Single Device 

In further detail, in the pending claims, the "smart card emulator" on the "server 
computer" receives smart card commands. In Davis, stored-value cards, which are 
separate devices from the security cards, are described as being associated with a client 
terminal and security cards are described as being associated with a payment server or a 
terminal separate from the payment server. A smart card emulator is never described as 
being associated with the payment server, which is necessary to anticipate the pending 
claims. The citations provided in the Final Rejection related to the "smart card emulator" 
are described in more detail as follows to support this assertion. 

In Column 11:28-37, Davis describes that the stored-value card can be termed a 
"smart card." Column 7:6-21 of Davis describes that the "stored-value card" is inserted 
into a physical card reader attached to a personal computer to make a purchase (In Davis, 
the personal computer is an example of a client terminal 204 shown in Fig. 4, which is a 
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different device than the payment server 206. The transaction amount associated with the 
purchase is captured by the security card.). In Column 11:48-57 of Davis, it describes that 
the security card authenticates the stored value card (i.e., the smart card). The "stored 
value card" and the "security card" of Davis are two different devices. Thus, the features 
of the stored value card associated with the client terminal can not be attributed to the 
payment server. 

In Column 10:50-53, Davis describes that the client terminal 204 controls the 
interactions with a user and interfaces to card reader 210. In Column 16:22-38 of Davis it 
also describes that a client module 224 located on a client terminal 204 can emulate a 
security card. Applicant believes the examiner may be trying to equate emulation of a 
security card on the client terminal with a smart card emulator on the payment server. 
Applicant believes that this would be improper because, as noted in the proceeding 
paragraphs, a security card and the stored- value card are different devices. Therefore, 
emulation of a security card on a client terminal can not be said to teach the functions of a 
smart card emulator on the payment server. 

Further, the Final Rejection does not identify a teaching in Davis that describes, 
as recited in the pending claims, "said smart card emulator arranged to retrieve one of 
said records from said virtual smart card database, and to deliver said monetary balance 
to said hardware security module," Whether Davis, as argued by the examiner in the 
examiner's answer supports, "operability is afforded to either a physical or virtual card," 
Davis still does not teach a smart card emulator located on the payment server with the 
limitations described in the pending claims. Thus, Davis can not be said to teach a single 
device with all of the required limitations because a smart card emulator as described in 
the pending claims is not taught as being associated with the payment server. 

In addition, the Final Rejection does not provide a rationale as to why "a smart 
card emulator" is inherently present on the payment server, which is necessary to map the 
payment server in Davis to the server computer of the pending claims. As noted in MPEP 
2112 IV, the examiner must provide rationale or evidence showing inherency because the 
fact that a certain result or characteristic may occur or be present in the prior art is not 
sufficient to establish the inherency of that result or characteristic. Applicant respectfully 
submits the Final Rejection does not satisfy this standard. For these reasons, Davis can 
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not be said to anticipate the pending claims and Applicant respectfully asserts the Final 
Rejection is improper. 

3. Pseudo Card Reader Module not on the Single Device 

The pending claims also recite the "server computer" comprises "said pseudo card 
reader module that receives said smart card commands related to said purchase 
transaction over said network and relays said commands to said smart card emulator." 
Applicant respectfully submits Davis does not describe a single device, i.e., the payment 
server, that includes this limitation along with the other limitations previously described. 
The Final Rejection states the pseudo card reader module is taught in Davis with respect 
to "Column 7:6-21, Column 8:22-24, Column 10:50-65 and Column 11:48-57." As 
described above, Column 7:6-21 teaches the use of a stored value card on a client 
terminal, such as a personal computer. Column 8: 22-24 describes the use of a security 
card associated with a payment server. Column 10:50-65 describes a client terminal that 
interfaces to a card reader that accepts a smart card. The client terminal also can talk to a 
payment server. Column 11:48-57 describes a security card. 

In Davis, a "server computer" comprising "a pseudo card reader module that 
receives said smart card commands" is not described. These smart card interactions are 
described as being performed by the client terminal not the payment server. Thus, the 
functions of the smart card on the client terminal can not be attributed to the payment 
server because, as discussed above, the security card associated with the payment server 
is a distinct device from a smart card. The Final Rejection does not provide reasoning or 
a basis as to why the pseudo card reader is inherently located on the payment server. 
Thus, Davis can not be said to teach a single device with all of the pending limitations 
because a pseudo card reader module as described in the pending claims is not taught nor 
is such a device associated with the payment server. For these reasons, Davis can not be 
said to anticipate the pending claims and Applicant respectfully asserts the Final 
Rejection under 102(e) is improper. 
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4. Single Device with a Virtual Smart Card Device, Smart Card Emulator 
and Pseudo-Card Reader Module is not enabled in Davis. 

Applicant respectfully submits that Davis can not be said to provide an enabling 
disclosure for a "virtual smart card database, a smart card emulator or a pseudo-card 
reader module." MPEP 2121.01, Use of Prior Art in Rejections where Operability in 
Question, states: 

In determining that quantum of prior art disclosure which is necessary to declare 
an applicant's invention 'not novel' or 'anticipated' within section 102, the stated 
test is whether a reference contains an 'enabling disclosure'... ." In re Hoeksema, 
399 F.2d 269, 158 USPQ 596 (CCPA 1968). The disclosure in an assertedly 
anticipating reference must provide an enabling disclosure of the desired subject 
matter; mere naming or description of the subject matter is insufficient, if it 
cannot be produced without undue experimentation. Elan Pharm., Inc. v. 
**>Mayo Found. For Med. Educ. & Research<, 346 F.3d 1051, 1054, 68 
USPQ2d 1373, 1376 (Fed. Cir. 2003). 
Applicant submits that the examiner's citation to Column 11:10-14 of Davis is a "mere 

naming" of the subject matter. 

Further, I. 35 USC 102 Rejections and Addition of Evidence Showing Reference is 

Operable states: 

It is possible to make a 35 USC 102 rejection even if the reference does not 
itself teach one of ordinary skill how to practice the invention, i.e., how to make 
or use the article disclosed. If the reference teaches every claimed element of the 
article, secondary evidence, such as other patents or publications, can be cited to 
show public possession of the method of making and/or using. In re Donohue, 
766 F.2d at 533, 226 USPQ at 621. 

Applicant does not agree with the examiner that the reference teaches every 

claimed element of the article as needed to sustain the rejection under 102(e). Further, 

assuming arguendo the reference did teach every element, the examiner in the rejection 

does not provide any secondary evidence, such as other patents or publications, to show 

public possession of the method of making or using. Therefore for these, Applicant 

respectfully submits that the examiner in the rejection under U.S.C. §102 (e) has not 

provided sufficient evidence that Davis includes enabling disclosure of the "virtual smart 

card database," "smart card emulator," and "pseudo-card reader. For these reasons, Davis 

can not be said to anticipate the pending claims and Applicant respectfully asserts the 

Final Rejection under 102(e) is improper. 
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C. Virtual Smart Card Database and Pseudo-Card Reader Module are not inherent 
in Davis nor is an Enabling Description provided for these Elements in Davis 

As argued in the Appeal Brief, the two elements "virtual smart card database," 
and "pseudo-card reader" of the pending claims are not explicitly described in Davis. The 
examiner's answer states, "In the absence of any evidence to the contrary, examiner 
continues to maintain that reference discloses and enables that a virtual smart card can be 
used." To establish these elements are inherent, the burden falls upon the examiner, not 
the Applicant, "to provide a basis in fact and/or technical reasoning to reasonably support 
the determination that the allegedly inherent characteristic necessarily flows from the 
teachings of the applied prior art." Applicant respectfully submits that the examiner in the 
rejection under U.S.C. §102 (e) has not provided sufficient basis in fact and/or technical 
reasoning to establish inherence of the "virtual smart card database," and "pseudo-card 
reader" in Davis. 

IV. CONCLUSION 

In view of the foregoing, Appellants respectfully request that the Board reverse 
the examiner's rejection under U.S.C. §102 (e) of all pending claims. In addition, 
Appellants believe all claims now pending in this application are in condition for 
allowance. The issuance of a formal Notice of Allowance at an early date is respectfully 
requested. 

Respectfully Submitted, 

BEYER LAW GROUP LLP 

/David P. Olynick/ 
David P. Olynick 
Reg. No.: 48,615 
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